A multimedia device may be a piece of mobile communication equipment such as a mobile telephone, PDA, or the like having functionality over and above a basic FM radio receiver. The multimedia device may however have no electronic functions other than those of a radio receiving apparatus.
The radio data system (RDS) is intended for application to VHF/FM sound broadcasts in the range 87.5 MHz to 108 MHz; these may carry either stereophonic or monophonic programs. The main objectives of RDS are to enable improved functionality of FM receivers and to make them more user-friendly by using features such as program identification, program service menu display and where applicable, automatic tuning for radios incorporated into mobile devices. This is done by providing (and using) information to supplement the audio radio transmission.
RDS is defined by the European Broadcasting Union (EBU)/Cenelec Standard EN50067: 1998, “Specification of the Radio Data System”. This standard is compatible with the United States radio broadcast data system (RBDS) defined by the US National Radio Systems Committee in the specification of the radio broadcast data system, dated 9 Apr. 1998. In the following, it should be understood that the term RDS refers to both the Radio Data System and the Radio Broadcast Data System, unless otherwise specified or apparent to the person skilled in the art.
FIG. 1 shows the structure of the baseband coding of the RDS standards, for example see FIG. 8 of EN50067: 1998. The largest element in the structure is called a group, consisting of 104 bits. Each group contains four blocks of 26 bits each. Each block contains an information word and a check word. Each information word comprises 16 bits, and each check word comprises 10 bits. The format and addressing structure of the information word of Blocks 1 and 2 are illustrated in FIG. 2A (see FIG. 9 of EN50067: 1998), and of the information words of Blocks 1, 2, 3 and 4 according to group type (see Block 2, FIG. 3 and explanation below) in FIG. 2B (i and ii).
As can, be seen from FIG. 2, the first block (Block 1) in every group always contains a program identification (PI) code. Furthermore, the first four bits of the second block (Block 2) of every group are allocated to a 4-bit code that specifies how the information within the group is to be applied. According to the Standard, groups are referred to as type 0 to 15 according to binary weighting A3=8, A2=4, A1=2, A0=1. For each type (0 to 15) two versions can be defined, versions A and B (FIG. 3). The version is specified by a fifth bit (B0) of block 2, and a mixture of version A and version B groups may be transmitted on one particular FM radio station. The Standard defines that if B0=0, the PI code is inserted in block 1 only (version A) and if B0=1, the PI code is inserted in block 1 and block 3 of all group types (version B).
The Standard defines that each block 2 contains a Group Type Code (GTC) defining the nature of the information word of the block (see FIG. 3, which provides a table of the group type codes for both versions A and B of the RDS encoding system and a brief description of the data content of each group). Furthermore, six locations in block 2 of every group are occupied by a program type code (PTY) and the traffic program identification (TP) code (FIG. 2 and FIG. 3).
The PI, PTY and TP codes can be decoded without reference to any block outside the ones that contain information relating to one of these codes. This is important to minimise acquisition time for these kinds of message and to retain the advantages of the short (26-bit) block length. To permit this to be done for the PI codes in block 3 of version B groups, a special offset word (commonly defined as C′) is used in block 3 of version B groups. The occurrence of offset C′ in block 3 of any group can then be used to indicate directly that block 3 is a PI code, without any reference to the value of B0 in block 2.
FIG. 4 shows a circuit 1 suitable for receiving FM radio including an RDS demodulator 5 and an RDS decoder 6. The output of the RDS decoder 6 is an RDS data signal which is input to a host processor 7 of a device. The circuit 1 is arranged such that an FM signal is received at the antenna 2 and demodulated by the very high frequency (VHF)/FM demodulator 3, which outputs a multiplexed signal to an audio decoder 4 and an RDS signal demodulator 5. The audio decoder 4 outputs a program audio signal which may consist of either a single sound channel (monophonic) or two sound channels (stereophonic). The program audio signal output by audio decoder 4 may then be amplified and used by the multimedia device. The RDS signal demodulator 5 demodulates the RDS signal from the multiplexed signal and outputs this to an RDS decoder 6. The RDS decoder 6 outputs an RDS data signal corresponding to the information word of a block. The RDS decoder 6 signals an interrupt to the host processor 7 when a new data block has been decoded. This can be after every block, which corresponds to one interrupt every 22 ms.
It is common for multimedia devices to incorporate an idle mode in order to reduce current consumption and increase battery life. In such an idle mode, the host processor of such a multimedia device may be substantially deactivated, such that a core of the processor is only activated in response to a particular flag being set in an on-chip register. This may occur, for example, upon the depression of a key of the multimedia device. Typically an FM radio application incorporated into a multimedia device operates when the multimedia device is in such an idle mode allowing for reduced current consumption by the radio. However, with the addition of a circuitry capable of decoding RDS as shown in FIG. 4, the processor of the multimedia device must wake up every 22 or 44 ms to service the interrupt. This activity of the host processor 7 results in an increase in current consumption. In the case of the multimedia device being battery operated, the inclusion of a circuitry capable of decoding RDS to an FM radio application may lead to a reduced radio listening time and further a reduced multimedia device operation time.
One option for mitigating this problem is to incorporate buffering in the circuit so that the host processor may receive an interrupt once every two blocks have been decoded, corresponding to an interrupt interval of 44 ms. However, this still requires the processor to be activated frequently and to be activated even if non-required data is being received.
It as an aim of embodiments of the present invention to solve at least one of the problems as described above.